Keyword: MVC,MVP,MVVM
在使用KMM上,架構是重中之重.如果使用了好的架構並且遵循,KMM就能幫助你達成事半功倍的效果,但是如果沒有好好遵守,不僅要為了每個平台進行特化,還會為了層出不窮的Bug疲於奔命,最後黯然放棄.
因此,雖然網路上關於MVC,MVP,MVVM的文章已經超級多了,我仍然會重複一次我的思路.我會試圖把架構講得比較輕鬆,容易暸解.
用一個生活上的例子來代表 :
假設你約好要到朋友家去玩,希望到車站時可以接你....
朋友回答: 好的,我會開一台1996年由福特生產,內部有配備A牌安全氣囊> > ......由台灣公司代理的白色小汽車,車牌是ACC-1425,我會漢口路右轉,再走民權西路.....最後在車站接你回來.如果朋友這樣回答,你一定是覺得說這麼多幹嘛?車子是怎麼生產,走什麼路來的,對於你來說,根本不是重點.
最常見的寫法,將所有事情都一鼓腦兒塞進同個地方之中,如何取資料,取完資料要做什麼什麼處理,怎麼傳遞,如何呈現在畫面上,通通在一個地方做完.
雖然有達到了功能面,但是在修改及維護上會有許多的麻煩,例如有天政府下令所有的汽車都要更新自動導航,就要一台一台車去檢查.隨著政府的要求越來越多,車子也變得越來越混亂.在測試時更是會測到吐出來,最後只能靠人去一個一個嘗試.
朋友回答:好的,我會開車去接你回來.不用知道車子的生產過程,也不用知道中間的路程.這些過程都交給朋友幫你處理好了.你所需要做的就是等朋友來然後舒舒服服的坐車去朋友家...等等,突然想到還沒買給女朋友的名產...那家店剛好跟你朋友家是反方向
我們將生產與傳遞資料的事物交給一個代理人(Presenter)全權處理,並不需要知道資料的來源.相信代理人會處理好這個部分的事物.View所需要做的就是等Presenter根據你的行為提供資料.
但是基本上就是跟這個Presenter綁定了,View需要知道Presenter,而Presenter也需要知道View.在畫面邏輯新增或修改的時候,需要同時改寫View和Presenter兩方,大幅增加工作量
朋友回答:好的,會有台車在那.到了車站有台車就停在你面前,你想要做什麼都可以....
ViewModel同樣是一個代理人的身份,與Presenter不同的地方在於,ViewModel不在意資料是
如何被使用的.ViewModel只負責提供資料,要拿去顯示在RecyclerView上也好,或是跳出Dialog也罷,那都是使用資料的View層所決定的.而View與ViewModel可以做的單方面的依賴就是利用到了觀察者模式的特性.
常常有人問,"使用了DataBinding或是LiveData,是不是就是MVVM了?",其實這些都是Google官方輔助的一種MVVM實作,還是要看怎麼使用,我曾看過新人每次使用到LiveData時全部使用getValue
而不是observe來接收數值變化.或是使用DataBinding時把整個View傳進ViewModel裡面,這些都失去了MVVM初始為了降低耦合程度的設計
而KMM的架構設計就有如最後一個MVVM的模式,內層的資料不了解被誰使用了,只知道有人要資料我就給他,也因此外層有再大的變化,甚至從Android換成iOS了,對於KMM的共用層都是一樣的.